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Command,  Control,  Communications,  and  Intelligence 
Node:  A  Durra  Application  Example 

Abstract:  Durra  is  a  language  designed  to  support  the  construction  of  distributed 
applications  using  concurrent,  coarse-grain  tasks  running  on  networks  of  hetero¬ 
geneous  processors.  An  application  written  in  Durra  describes  the  tasks  to  be 
instantiated  and  executed  as  concurrent  processes,  the  types  of  data  to  be  ex¬ 
changed  by  the  processes,  and  the  intermediate  queues  required  to  store  the  data 
as  they  move  from  producer  to  consumer  processes. 

This  report  describes  an  experiment  in  implementing  a  command,  control,  com¬ 
munications  and  intelligence  (C3I)  node  using  reusable  components.  The  exper¬ 
iment  involves  writing  task  descriptions  and  type  declarations  for  a  subset  of  the 
TRW  testbed,  a  collection  of  C3I  software  modules  developed  by  TRW  Defense 
Systems  Group.  The  experiment  illustrates  the  development  of  a  typical  Durra 
application.  This  is  a  three-step  process:  first,  a  collection  of  tasks  (programs)  is 
designed  and  implemented  (these  are  the  testbed  programs);  second,  a  collection 
of  task  descriptions  corresponding  to  the  task  implementations  is  written  in  Durra, 
compiled,  and  stored  in  a  library;  and  finally,  an  application  description  is  written  in 
Durra  and  compiled,  resulting  in  a  set  of  resource  allocation  and  scheduling  com¬ 
mands  to  be  interpreted  at  runtime. 

This  report  illustrates  the  methodology  for  building  complex,  distributed  systems 
supported  by  Durra.  It  does  not,  however,  illustrate  all  the  features  of  the  lan¬ 
guage;  in  particular,  it  does  not  illustrate  those  features  that  support  dynamic,  but 
planned,  reconfiguration  of  a  running  application,  or  those  features  supporting  un¬ 
planned  dynamic  reconfigurations  as  a  means  to  support  fault  tolerance.  These 
considerations  are  the  subject  of  current  design  and  development  and  will  be  the 
subject  of  a  future  report. 


1.  Introduction  to  Durra 


Durra  [1,2]  is  a  language  designed  to  support  the  construction  of  distributed  applications 
using  concurrent,  coarse-grained  tasks  running  on  networks  of  heterogeneous  processors. 
An  application  written  in  Durra  selects  and  reuses  task  descriptions  and  type  declarations 
stored  in  a  library.  The  application  describes  the  tasks  to  be  instantiated  and  executed  as 
concurrent  processes,  the  types  of  data  to  be  exchanged  by  the  processes,  and  the  interme¬ 
diate  queues  required  to  store  the  data  as  they  move  from  producer  to  consumer  processes. 

Because  tasks  are  the  primary  building  blocks,  we  refer  to  Durra  as  a  task-level  description 
language.  We  use  the  term  “description  language"  rather  than  “programming  language"  to 
emphasize  that  a  Durra  application  is  not  translated  into  object  code  in  some  kind  of  ex¬ 
ecutable  (conventional)  “machine  language.”  Instead,  a  Durra  application  is  a  description  of 
the  structure  and  behavior  of  a  logical  machine  to  be  synthesized  into  resource  allocation 
and  scheduling  directives  that  are  then  interpreted  by  a  combination  of  software,  firmware, 
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Allocate  queue 
Shutdown 


Figure  1-1:  Compilation  of  an  Application  Description 


and  hardware  in  each  of  the  processors  and  buffers  of  a  heterogeneous  machine.  This  is 
the  translation  process  depicted  in  Figure  1-1 . 


1 .1 .  Type  Declarations 

The  data  types  transmitted  between  the  tasks  are  declared  independently  of  the  tasks.  In 
Durra,  these  data  type  declarations  specify  scalars  (of  possible  variable  length),  arrays, 
simple  record  types,  or  unions  of  other  types,  as  shown  in  Figure  1-2. 


type  packet  Is  size  128  to  1024; 


type  tails  is  array  (5  10)  of  packet; 


—  Packets  are  of  variable  length. 


—  Tails  are  5  by  10  arrays  of  packets, 
type  rec  Is  record  (rows:  integer,  columns:  integer,  data:  packet); 

—  Rec  data  consists  of  two  integers  and  a  packet, 
type  mix  is  union  (heads,  tails); 


—  Mix  data  could  be  heads  or  tails. 


Figure  1-2:  Durra  Type  Declarations 
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1.2.  Task  Descriptions 

Task  descriptions  are  the  building  blocks  for  applications.  A  task  description  includes  the 
following  information  (Figure  1-3):  (1)  its  interface  to  other  tasks  (ports);  (2)  its  attributes; 
(3)  its  functional  and  timing  behavior;  and  (4)  its  internal  structure,  thereby  allowing  for 
hierarchical  task  descriptions. 


task  task-name 

ports  —  Used  tor  communi cation  between  a  process  and  a  queue 

port-declarations 

attributes  —  Used  to  specify  miscellaneous  properties  of  the  task 

attribute-value-pairs 

behavior  —  Used  to  specify  task  functional  and  timing  behavior 

functional  specification 
timing  specification 


Structure  —  A  graph  describing  the  internal  structure  of  the  task 

process-declarations  — Declaration  of  instances  of  internal  subtasks 

bind-declarations  —  Mapping  of  internal  ports  to  this  task's  ports 

queue-declarations  —  Means  of  communication  between  processes 

reconfiguration-statements  —  Dynamic  modifications  to  the  structure 

end  task-name 


Figure  1-3:  A  Template  for  Task  Descriptions 


The  interface  information  declares  the  ports  of  the  processes  instantiated  from  the  task.  A 
port  declaration  specifies  the  direction  and  type  of  data  moving  through  the  port.  An  in  port 
takes  input  data  from  a  queue;  an  out  port  deposits  data  into  a  queue: 
ports 

ini:  In  haads; 

outl,  out2:  out  tails; 

The  attribute  information  specifies  miscellaneous  properties  of  a  task.  Attributes  are  a 
means  of  indicating  pragmas  or  hints  to  the  compiler  and/or  scheduler.  In  a  task  descrip¬ 
tion,  the  developer  of  the  task  lists  the  actual  value  of  a  property;  in  a  task  selection,  the 
user  of  a  task  lists  the  desired  value  of  the  property.  Example  attributes  include  author, 
version  number,  programming  language,  file  name,  and  processor  type: 

attributes 

author  =  "jmw"; 

implementation  =  "programjiaina" ; 

Queue  Size  =*  25; 


The  behavioral  information  specifies  functional  and  timing  properties  about  the  task.  The 
functional  information  part  of  a  task  description  consists  of  a  pre-condition  on  what  is  re¬ 
quired  to  be  true  of  the  data  coming  through  the  input  ports,  and  a  post-condition  on  what  is 
guaranteed  to  be  true  of  the  data  going  out  through  the  output  ports.  The  timing  expression 
describes  the  behavior  of  the  task  in  terms  of  the  operations  it  performs  on  its  input  and 
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output  ports.  For  additional  information  about  the  syntax  and  semantics  of  the  functional 
and  timing  behavior  description,  see  the  Durra  reference  manual  [1]. 

The  structural  information  defines  a  process-queue  graph  (e.g.,  Figure  1-1)  and  possible 
dynamic  reconfiguration  of  the  graph  as  shown  in  Figure  1-4. 


task  comm 

—  rod  communications 
ports 

SM__Commands 
SM__Respon  sea 
Inbound 
Outbound 
structure 


processing 

in  sy  s t  em_command ; 
out  aubsystem_response; 
out  comm_if_message; 
in  comm_i  f _roe  s  s  age  ; 


process 


cc 

ci 

CO 


pb 


pm 


task  comm_control; 
task  comm_inbound ; 
task  comm_outbound ; 
task  broadcast 
port 

ini  :  in  system_command; 

outl,  out 2  :  out  system_coxnmand; 

end  broadcast; 
task  merge 
port 

ini,  in2  :  in  subayatem_response; 
outl  :  out  subsystexnjresponse; 

attribute 

mode  =  fifo; 


end  merge; 


bind 


queue 


end  comm; 


SM_Commands 
SM_Re  spo  n  ses 
Inbound 
Outbound 


—  cc.SM_In; 

»  cc . SM_Out ; 

=  ci.  Inbound; 

=»  co .  Outbound; 


qi 

q2 

q3 

q4 

q5 

q6 

q7 


cc . Cmd__Out 
pb . out 1 
pb. out2 
ci . Resp_Out 
co . Resp_Out 
pm.  outl 
co. Echo  Out 


»  pb . ini; 

»  ci . Cmd_In ; 
»  co . Cmd_In ; 
»  pm.  ini; 

»  pm.in2; 

»  cc.Resp_In; 
»  ci.Echo  In; 


Figure  1-4:  Compound  Task  Description 


A  process  declaration  of  the  form 

proc9SS_name  :  task  task_selection 

creates  a  process  as  an  instance  of  the  specified  task.  Since  a  given  task  (e.g., 
convolution)  might  have  a  number  of  different  implementations  that  differ  along  different 
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dimensions  such  as  algorithm  used,  code  version,  performance,  or  processor  type,  the  task 
selection  in  a  process  declaration  specifies  the  desirable  features  of  a  suitable  implemen¬ 
tation.  The  presence  of  task  selections  within  task  descriptions  provides  direct  linguistic 
support  for  hierarchically  structured  tasks. 

A  queue  declaration  of  the  form 

queue_name  [queue_size\:  port_name_  1  >  data_transformation  >  port_name_2 

creates  a  queue  through  which  data  flow  from  an  output  port  of  a  process  (port_name_1 ) 
into  the  input  port  of  another  process  (port_name_2).  Data  transformations  are  operations 
applied  to  data  coming  from  a  source  port  before  they  are  delivered  to  a  destination  port. 

A  port  binding  of  the  form 

task _port  =  process _port 

maps  a  port  on  an  internal  process  to  a  port  defining  the  external  interface  of  a  compound 
task. 

Although  not  illustrated  in  the  figure,  Durra  provides  a  reconfiguration  statement  of  the  form 

if  condition  then 

remove  process-names 
process  process-declarations 
queues  queue-declarations 

end  if; 

as  a  directive  to  the  scheduler.  It  is  used  to  specify  changes  in  the  current  structure  of  the 
application  (i.e.,  process-queue  graph)  and  the  conditions  under  which  these  changes  take 
effect.  Typically,  a  number  of  existing  processes  and  queues  are  replaced  by  new  proc¬ 
esses  and  queues,  which  are  then  connected  to  the  remainder  of  the  original  graph.  The 
reconfiguration  predicate  is  a  Boolean  expression  involving  time  values,  queue  sizes,  and 
other  information  available  to  the  scheduler  at  runtime. 


1.3.  Scenario 

We  see  three  distinct  phases  in  the  process  of  developing  an  application  using  Durra:  the 
creation  of  a  library  of  tasks,  the  creation  of  an  application  using  library  tasks,  and  the  ex¬ 
ecution  of  the  application.  These  three  phases  are  illustrated  in  Figure  1-5. 

During  the  first  phase,  the  developer  writes  descriptions  of  the  component  tasks  and 
declarations  of  the  data  types.  The  type  declarations  specify  the  kinds  of  data  that  will  be 
produced  and  consumed  by  the  tasks  in  the  application.  The  task  descriptions  specify  the 
properties  of  the  task  implementations  (programs).  For  a  given  task,  there  may  be  many 
implementations,  differing  in  programming  language  (e.g.,  C  or  assembly  language),  proces¬ 
sor  type  (e.g.,  Motorola  68020  or  IBM  1401),  performance  characteristics,  or  other  attri¬ 
butes.  For  each  implementation  of  a  task,  a  description  must  be  written  in  Durra,  compiled, 
and  entered  in  the  library. 
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Library  of  Task 

Descriptions 

(Durra) 


Library  of  Task 
Implementations 
(C, Lisp, Ada, etc.) 


Figure  1-5:  Scenario  for  Developing  an  Application  in  Durra 


During  the  second  phase,  the  user  writes  an  application  description.  Syntactically,  an  appli¬ 
cation  description  is  a  single  task  description  and  could  be  stored  in  the  library  as  a  new 
task.  This  allows  writing  of  hierarchical  application  descriptions.  When  the  application  de¬ 
scription  is  compiled,  the  compiler  generates  a  set  of  resource  allocation  and  scheduling 
commands  or  instructions  to  be  interpreted  by  the  scheduler. 

During  the  last  phase,  the  scheduler  loads  the  task  implementations  (i.e.,  programs  cor¬ 
responding  to  the  component  tasks)  into  the  processors  and  issues  the  appropriate  com¬ 
mands  to  execute  the  programs. 
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1.4.  Runtime  Components 

There  are  three  active  components  in  the  Durra  runtime  environment:  the  application  tasks, 
the  Durra  server,  and  the  Durra  scheduler.  Figure  1-6  shows  the  relationship  among  these 
components. 


Figure  1-6:  The  Durra  Runtime  Environment 


After  compiling  the  type  declarations,  the  component  task  descriptions,  and  the  application 
description,  as  described  previously  and  illustrated  in  figure  1-5,  the  application  can  be  ex¬ 
ecuted  by  performing  the  following  operations: 


1 .  The  component  task  implementations  must  be  stored  in  the  appropriate 
processors. 

2.  An  instance  of  the  Durra  server  must  be  started  in  each  processor. 

3.  The  scheduler  must  be  started  in  one  of  the  processors.  The  scheduler 
receives  as  an  argument  the  name  of  the  file  containing  the  scheduler  pro- 
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gram  generated  by  the  compilation  of  the  application  description.  This  step 
initiates  the  execution  of  the  application. 

1.4.1.  The  Scheduler 

The  scheduler  is  the  part  of  the  Durra  runtime  system  responsible  for  starting  the  tasks, 
establishing  communication  links,  and  monitoring  the  execution  of  the  application.  In  addi¬ 
tion,  the  scheduler  implements  the  predefined  tasks  (broadcast,  merge,  and  deal)  and  the 
data  transformations  described  in  [1],  The  scheduler  is  invoked  with  the  name  of  the  file 
containing  the  scheduler  instructions  generated  by  the  Durra  compiler.  A  complete  descrip¬ 
tion  of  the  scheduler  instructions  can  be  found  in  [3]. 

After  these  instructions  have  been  read  and  processed,  the  scheduler  is  ready  to  start  the 
execution  of  the  application.  In  the  current  Unix  implementation,  this  is  done  by  performing 
the  following  steps: 

1 .  Allocate  a  Unix  socket  for  communication  with  the  application  tasks. 

2.  Establish  communication  with  each  of  the  processors  running  a  Durra  server. 

3.  For  each  of  the  taskjoad  instructions,  issue  to  the  appropriate  server  a 
run_task  remote  procedure  call. 

4.  Listen  in  on  the  Unix  socket  allocated  in  the  first  step  for  remote  procedure 
.  calls  from  the  application  tasks. 

5.  Process  the  remote  procedure  calls  from  the  application  tasks. 

The  scheduler  waits  until  all  tasks  have  completed  their  execution  before  it,  in  turn,  finishes 
its  execution. 

1 .4.2.  The  Server 

The  server  is  responsible  for  starting  tasks  on  its  corresponding  processor,  as  directed  by 
the  scheduler.  One  copy  of  the  server  must  be  running  on  each  processor  that  is  to  execute 
Durra  tasks. 

When  a  server  begins  execution,  it  listens  in  on  a  predetermined  socket  for  messages  from 
the  scheduler.  Once  a  communication  channel  is  open,  the  scheduler  communicates  with 
the  server  using  a  set  of  remote  procedure  calls  to  initiate  task  execution  (run_task),  or  to 
shutdown  or  restart  the  server  (shutdown,  and  restart).  Complete  details  of  these  remote 
procedure  calls  can  be  found  in  [3].  The  server  sits  in  a  loop  responding  to  the  requests 
from  the  scheduler,  executing  them  as  directed. 

1.4.3.  Application  Tasks 

The  component  task  implementations  making  up  a  Durra  application  can  be  written  in  any 
language  for  which  a  Durra  interface  has  been  provided.  As  of  this  writing,  there  are  Durra 
interfaces  for  both  C  and  Ada.  The  complete  interfaces  appear  in  [3]. 

When  a  task  is  started,  the  scheduler  supplies  it  with  the  following  information  (via  a  server): 
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the  name  of  the  host  on  which  the  scheduler  is  executing,  the  Unix  socket  on  which  the 
scheduler  is  listening  for  communications  from  the  task,  and  a  small  integer  to  be  used  in 
identifying  the  task  in  future  messages. 


Application  tasks  use  the  interface  to  the  scheduler  to  communicate  with  other  tasks.  From 
the  point  of  view  of  the  task  implementation,  this  communication  is  accomplished  via  proce¬ 
dure  calls,  which  return  only  when  the  operation  is  completed.  The  following  remote  proce¬ 
dure  calls  (RPCs)  are  provided: 


init 

finish 

get_portid 

get_typeid 

send_port 

get_port 

test_input_port 

test_output_port 


Opens  a  connection  to  the  scheduler. 

Informs  the  scheduler  that  the  task  is  terminating. 

Returns  a  descriptor  for  the  application  task  to  use  when  referring  to  a 
port. 

Returns  a  descriptor  for  the  application  task  to  use  when  referring  to  a 
type. 

Sends  data  through  an  output  port  of  the  application  task. 

Gets  data  from  an  input  port  of  the  application  task. 

Tests  whether  data  is  available  on  an  input  port. 

Tests  whether  there  is  room  in  a  queue  attached  to  an  output  port. 


Durra  tasks  typically  use  these  RPCs  in  the  following  order: 


1 .  Call  init  to  establish  communication  with  the  scheduler. 

2.  Call  get_portid  for  each  of  the  task  ports  (these  ports  must  correspond  to  the 
ports  used  in  the  task  description). 

3.  Call  get_typeid  for  each  of  the  task  types  (these  types  must  correspond  to  the 
data  types  used  in  the  task  description). 

4.  Call  send_port  and  get_port  as  necessary  to  send  and  receive  data. 

5.  Call  finish  to  break  communication  with  the  scheduler. 
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2.  Introduction  to  the  TRW  C3I  Testbed 


The  TRW  command,  control,  communications,  and  intelligence  (C3I)  testbed  is  a  collection 
of  programs  that  implement  a  variety  of  functions  found  in  command,  control,  communica¬ 
tions,  and  intelligence  systems.  They  have  been  developed  as  a  part  of  the  Reusable  C3I 
Node  Independent  Research  and  Development  Project  at  TRW  Defense  Systems  Group. 
The  overall  objective  of  this  project  is  to  reduce  the  cost  and  schedule  for  fielding  state-of- 
the-art,  next  generation  C3I  systems.  TRW  plans  to  achieve  this  objective  by  developing  a 
standardized  architectural  framework  for  C3I  systems  and  reusable  hardware  and  software 
components  that  are  applicable  over  a  wide  range  of  target  systems.  The  technical  objec¬ 
tives  for  the  Reusable  C3I  Node  Project  are  to  1)  develop  a  reusable  C3I  system  architec¬ 
ture,  including  hardware  and  software  components;  2)  develop  software  and,  if  necessary, 
hardware  components  as  building  blocks  within  the  architecture;  and  3)  test  the  flexibility  of 
the  architecture  and  components  by  demonstrating  them  on  several  actual  target  C3I  sys¬ 
tems. 

In  the  remainder  of  this  chapter  we  will  address  only  one  of  several  tasks  identified  by  TRW 
as  critical  to  their  overall  objective,  namely  the  development  of  an  architecture  framework  in 
which  various  C3I  system  building  blocks  fit.  This  would  be  used  to  define  the  interfaces 
and  the  possible  combinations  of  building  blocks  during  the  definition  of  the  reusable  system 
baseline,  and  to  help  during  the  integration  and  testing  of  the  application  system.  Other 
major  tasks,  not  addressed  in  this  report,  include  software  component  definition  and  devel¬ 
opment,  hardware  component  selection  and  integration,  and  testbed  integration  and  demon¬ 
stration. 


2.1.  C3I  Node  Hardware  Architecture 

The  architecture  adopted  for  the  reusable  C3I  node  and  its  testbed  is  open  so  that  any 
vendor’s  equipment  could  be  connected  and  the  node  software  integrated  with  the  vendor- 
supplied  hardware  and  system  software.  To  reach  this  goal  of  an  open  system  architecture, 
it  is  necessary  to  have  a  paradigm  for  programming  loosely-connected  networks  of  multiple 
special-  and  general-purpose  processors.  This  is  the  role  played  by  the  Durra  language  and 
methodology.  The  need  for  experimenting  with  paradigms  for  heterogeneous  networks  pro¬ 
vided  the  motivation  for  a  joint  effort  between  TRW  Defense  Systems  Group  and  the  Soft¬ 
ware  Engineering  Institute. 

C3I  systems  have  similar  requirements  and  functions  whether  the  system  is  for  tactical  or 
strategic  forces,  whether  it  is  fixed-base  or  mobile,  or  whether  it  is  controlling  planes,  tanks, 
or  ships.  The  purpose  of  all  such  systems  is  to  give  up-to-the-minute  information  to  com¬ 
manders  at  each  echelon  to  assist  them  in  making  decisions  and  to  speed  implementation 
of  these  decisions.  The  top-level  description  of  a  typical  tactical  C3I  system  is  shown  in 
Figure  2-1.  This  system  consists  of  a  network  of  geographically  separated  nodes  where 
each  node  is  a  local  area  network  of  processors.  Communication  among  the  nodes  (located 
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at  command  posts)  is  via  combat  net  radios  or  land  lines  and  consists  of  messages  whose 
format  and  protocol  is  tightly  controlled  by  Army  standards  and  doctrine.  Each  node  con¬ 
tains  a  database  representing  the  battle  situation  (deployment  of  friendly  and  enemy  forces) 
and  the  status  of  forces  controlled  by  this  command  post.  The  overall  information  flow  for 
the  system  is  predominantly  hierarchical,  with  messages  containing  orders  or  requests  for 
information  flowing  from  upper  echelons  to  lower  echelons  and  messages  containing  status 
and  situation  reports  flowing  back  to  the  upper  echelons. 

Each  node  consists  of  a  network  of  computers  whose  purpose  is  to  process  operator  re¬ 
quests  for  information,  to  act  on  incoming  messages  (by  showing  them  to  an  operator  or 
replying  automatically),  and  to  maintain  the  situation  and  status  database.  The  .computers 
at  a  node  may  be  concentrated  in  a  command  post  structure  (shelter,  tent,  or  parked 
vehicle)  or  dispersed  among  several  structures  for  concealment.  They  typically  communi¬ 
cate  via  Ethernet  or  fiber-optic  equivalents.  At  this  level  the  communications  protocols  are 
not  restricted  and  may  support  exchange  of  message  text,  database  information, 
keyboard/screen  information,  etc.  At  each  node  in  the  system  common  processing  is  done: 
communications  equipment  management,  message  processing,  data  management,  man¬ 
agement  of  the  LAN,  and  interaction  with  the  operators.  In  addition,  a  node  may  have 
unique  application  responsibilities  such  as  resource  allocation,  planning,  and  decision 
making. 


2.2.  C3I  Node  Software  Architecture 

TRW  has  defined  a  nodal  software  architecture  which  supports  both  the  common  process¬ 
ing  functions  and  site-  or  system-specific  ones.  As  shown  in  Figure  2-2,  the  architecture  is 
extensively  layered  to  support  the  open  architecture  concepts  described  above.  In  addition 
to  multiple  vendors,  the  architecture  supports  redistribution  of  functions  among  processors 
to  support  networks  containing  from  1  to  50  processors.  The  reusable  C3I  node  IR&D  Proj¬ 
ect  is  building  software  components  for  the  shaded  functional  areas  in  the  diagram.  These 
components  are  implemented  as  Ada  tasks  and  packages.  The  tasks  communicate  via 
messages  using  services  provided  by  the  Heterogeneous  InterProcess  Communication 
(IPC)  function;  in  the  testbed,  alternative  IPC  functions  have  been  implemented,  one  with 
the  Durra  runtime  environment  and  one  with  a  TRW-developed  IPC.  Figure  2-3  shows  the 
top-level  data  flow  in  a  system  constructed  from  the  components. 

The  "communication  processing”  area  is  a  support  subsystem  which  performs  all  of  the 
processing  associated  with  sending  and  receiving  messages  to  or  from  other  nodes  in  the 
system.  It  typically  consists  of  a  collection  of  hardware  and  firmware  interfaces  to  the  com¬ 
munications  media  and  software  to  coordinate  the  operation  of  the  subsystem.  The  tasks, 
which  are  top-level  components  of  the  communication  processing  subsystem,  include  media 
service,  inbound  message  processing,  outbound  message  processing,  data  services  (log, 
archive,  etc.),  and  communication  control. 

The  “automated  message  handling  (amh)”  area  is  a  subsystem  which  performs  all  proc- 
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Figure  2-1 :  C3I  System  Structure  —  Army  Tactical  System 
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Figure  2-2:  Reusable  C3I  Node  Architecture  Layers 
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Figure  2-3:  Data  Flow  Among  Nodal  Software  Components 
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essing  of  the  text  of  incoming  and  outgoing  messages  for  a  node.  For  incoming  messages, 
it  identifies  the  message  type  and  verifies  that  it  is  correctly  formatted,  extracts  data  from  the 
message  to  update  the  database,  and  disseminates  the  message  to  intended  recipients  at 
the  workstations.  Outgoing  message  processing  consists  of  review  and  message  release 
routing  within  the  node.  The  tasks  which  are  the  top-level  components  of  the  "AMH”  sub¬ 
system  are  inbound  message  processing,  outbound  message  processing,  and  control. 

The  "system  management”  area  performs  all  of  the  executive  and  control  functions  for  the 
nodal  network.  This  includes: 

•  system  startup,  shutdown,  and  reconfiguration 

•  user  login,  access  verification,  and  logout 

•  error  reporting  and  monitoring 

•  health  and  performance  monitoring 

The  components  of  system  management  are  the  overall  system  manager  task  and  a  sub¬ 
sidiary  workstation  manager  task  at  computers  for  each  operator  station.  Computers  which 
perform  only  background  processing  do  not  contain  a  workstation  manager. 

The  "data  management”  area  performs  all  database  access  and  control  functions  for  a 
node.  In  most  systems  this  is  a  commercial  relational  database  management  system  such 
as  SYBASE,  ORACLE,  etc.,  but  may  be  as  simple  as  a  flat-file  record  handling  system 
which  keeps  the  data  in  primary  memory.  The  components  of  this  subsystem  are  the  DBMS 
servers  and  the  distributed  server  and  client  control  logic. 

The  "user/system  interface  (usi)”  area  manages  all  interaction  with  the  operators  at  each 
workstation  in  the  node.  This  is  a  complicated  subsystem  which  contains  window  manag¬ 
ers,  main  menu  (or  other  user  selection  mechanism)  managers,  text  and  graphic,  tool  sup¬ 
port  libraries,  and  other  software  to  support  a  multi-window,  networked  environment. 

The  “application  support”  area  provides  interface  and  scheduling  services  for  application 
tasks  and  contains  the  common  office  automation  applications  like  electronic  mail,  word 
processing,  and  spreadsheets.  The  scheduling  services  include  message  event  scheduling, 
database  event  scheduling,  and  time  scheduling  of  application  tasks. 

The  definition  of  the  architecture  and  the  implementation  of  the  software  components  for  the 
C3I  testbed  coincide  with  the  Durra  paradigm  in  many  ways: 

•  Utilizing  libraries  of  reusable  ”black-box“  tasks. 

•  Describing  the  connectivity  of  the  system  outside  the  code  of  the  task. 

•  Using  message-oriented  communication  between  the  tasks. 

•  Describing  data  transformations  during  the  transmission  of  the  messages. 

The  flexibility  and  control  over  system  operation  provided  by  this  paradigm  are  central  to  the 
open  architecture  concept  and  the  ability  to  reuse  the  developed  software  modules.  In  the 
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remainder  of  this  report,  we  will  illustrate  the  use  of  Durra  to  build  applications  consisting  of 
C3I  node  software  modules  in  which  the  various  tasks  connected  through  queues  exchange 
messages. 
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3.  Task  and  Application  Descriptions 

In  this  chapter  we  illustrate  the  various  kinds  of  descriptions  that  would  be  written  in  a  typical 
application  of  Durra.  The  examples  depict  increasingly  more  complex  task  descriptions.  We 
first  show  a  simple  task  description,  of  a  task  implemented  by  a  single  program  and  capable 
of  running  on  one  of  the  processors  in  a  heterogeneous  network.  We  then  show  a 
compound  task  description,  that  is,  a  task  that  consists  of  several  simpler  tasks  whose  ports 
are  connected  via  data  queues.  Finally,  we  show  an  application  description  which,  syntac¬ 
tically,  looks  like  a  compound  task  description  and  ties  together  all  of  the  component  tasks 
(simple  or  otherwise)  of  an  application. 


3.1.  A  Simple  Task  Description  and  Its  Implementation 

In  this  section  we  illustrate  the  relation  between  a  Durra  task  description,  a  task  implemen¬ 
tation,  and  the  interface  between  the  task  implementation  and  the  Durra  runtime  environ¬ 
ment.  The  task  we  have  selected  is  the  control  module  of  the  Automatic  Message  Handler 
in  the  C3I  node. 

As  described  in  Section  2.2,  the  automated  message  handling  subsystem  of  the  C3I  node 
performs  all  processing  of  the  text  of  incoming  and  outgoing  messages  for  a  node.  As  we 
show  in  this  and  in  later  sections,  this  subsystem  consists  of  several  tasks.  One  of  these 
tasks,  ‘‘amhs_control,”  is  responsible  for  the  overall  operation  of  the  subsystem  and  per¬ 
forms  its  job  by  sending  requests  to  the  other  components  of  the  subsystem  and  processing 
their  responses.  In  addition,  it  provides  the  interface  to  other  subsystems  of  the  C3I  node, 
specifically,  the  system  manager  subsystem. 


task  axnh *_cont ro  1 
ports 

SM_In  :  in  syatem_coramand; 

SM_Out  :  out  subsystain__rasponse; 
Qmd_Out  :  out  ayatexn_comxnand; 
Raap_In  :  in  subsyatem_responae; 
attributes 

ixnpl  «mh tat  ion  »  ”amh_ control” ; 
xlOvindow  -  "=80x12+0+0” ; 
xllwindow  =  "-geometry  80x12+0+0"; 
processor  =  sun; 
end  amhs  control ; 


Figure  3-1 :  AMHS_Control  T ask  Description 


Figure  3-1  shows  the  Durra  description  of  the  “amhs_contror  task.  The  interface  portion  of 
the  task  description  indicates  that  it  consumes  data  of  type  “system_command"  and 
"subsystem_response”  through  input  ports  “SM_ln"  and  “Respjn,”  and  produces  data  of 
type  “subsystem_response”  and  "system_command”  through  output  ports  “SM_Out"  and 
"Cmd_Out,”  respectively. 
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The  attributes  of  the  task  description  provide  additional  information  about  the  task.  These 
include  the  name  of  the  task  implementation  (i.e.,  “amh_control”  is  the  actual  executable 
program),  the  name  of  the  processor  or  processor  class  on  which  this  implementation  can 
execute  ("sun”),  and  the  specifications  of  a  window  geometry  to  be  used  for  communication 
between  a  human  operator  and  the  task.  Notice  that  two  alternative  window  specifications 
are  provided,  depending  on  which  version  of  the  window  manager  is  running  on  the  proces¬ 
sor  to  which  the  task  will  be  allocated  at  runtime. 

As  indicated  in  Figure  1-5,  for  each  task  description,  there  is  a  corresponding  task  imple¬ 
mentation.  The  latter  is  a  program  that  will  be  loaded,  at  runtime,  on  one  of  the  machines  on 
the  network  and  will  communicate  with  other  task  implementations  through  ports.  The  task 
description  indicates  that  this  is  a  program  that  can  run  on  a  Sun  workstation  and  that  it 
communicates  with  a  human  operator  through  a  small  window  (12  lines  of  80  characters). 
This  window  specification  is  necessary  because  this  task  runs  as  an  independent,  interac¬ 
tive  program,  with  its  own  terminal  emulator  running  in  the  window.  The  server  [3]  running 
on  the  Sun  workstation  uses  the  window  specification  as  part  of  the  Unix  task  initiation  com¬ 
mand. 

The  task  implementation  in  this  example  is  an  Ada  program,  as  shown  in  figure  3-2.  This 
program  consists  of  a  main  unit,  the  procedure  listed  in  the  Figure  (“AMH_Contror’),  and  a 
separately  compiled  procedure  (“AMH_Control_Processing"),  not  shown  here.  The  main 
unit  in  this  program  is  responsible  for  1)  establishing  a  connection  with  the  Durra  scheduler 
(call  to  “Init”),  2)  getting  a  small  integer  token  to  identify  each  of  its  ports  (calls  to 
"Get_PortlD”).  3)  invoking  the  separate  procedure,  where  the  bulk  of  the  application  spe¬ 
cific  work  is  done,  and,  finally,  4)  notifying  the  Durra  scheduler  when  it  has  completed  its 
execution  (call  to  “Finish”). 

Notice  the  correspondence  between  the  port  names  used  in  the  calls  to  “Get_PortlD”  in  the 
task  implementation  of  Figure  3-2  and  the  port  names  used  in  port  declarations  in  the  task 
description  of  Figure  3-1. 

The  separately  compiled  procedure  ("AMHS_Control_lmplementation")  uses  the  port  iden¬ 
tifier  tokens  collected  by  the  main  procedure  to  invoke  various  input  and  output  operations 
on  these  ports.  This  procedure  is  rather  lengthy,  and  instead  of  including  the  entire  text ,  we 
illustrate  these  port  operations  via  a  small  segment  of  “AMH_Control_Processing”,  the  pro¬ 
cedure  (“Read_Next_Message”)  shown  in  Figure  3-3.  The  small  procedure  loops  contin¬ 
uously,  testing  for  the  presence  of  messages  on  the  input  ports  (calls  to  “Test_lnput_Port"). 
If  there  is  at  least  one  message  on  either  of  the  ports,  the  procedure  reads  the  message  into 
a  buffer  (calls  to  “Get_Port”)  and  returns  to  the  caller. 

There  are  a  few  more  interface  procedures  to  support  the  communication  between  the  user 
task  implementations  and  the  Durra  scheduler.  However,  for  the  purposes  of  this  report,  it  is 
not  necessary  to  go  into  further  details.  The  complete  interface  to  the  scheduler  is  de¬ 
scribed  in  [3].  Appendix  G  contains  the  specifications  of  the  interface  package  for  Ada  pro¬ 
grams. 
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with  Ipc_Typ««;  u««  Ipc_Typ«a; 

with  T«xt_Io;  u««  T«xt__Io; 

with  Int«rfac«; 


procedure  AMH_Control  is 
pragma  Priority (4); 
Process_ID 
size 
bound 
Verbose 


:  Integer  :»  1001; 

:  Integer; 

:  Integer; 

:  constant  Boolean  :  =*  True; 


SM_In_Port 
SM_Out_Port 
Cmd_Ou t_Po  rt 
Re  sp— I  n_ Port 


Positive; 

Positive; 

Positive; 

Positive; 


procedure  AMH_Control_Processing  (  Process_ID  :  in  Integer) 

is  separate; 


begin 

Put^Line  (  ******  amh— control  ******  ); 

Interface . Init ; 

Interface.  Get— Port  ID  (,,SHM_InH ,  SM_In_ Port,  bound,  size); 
Interface .  Get^_ Port  ID  ( "  SM_Out " ,  SM_Out_Port ,  bound,  size)  ; 
Interface.  Get— Port  ID  ("Cmd^Out** ,  Crad__Out__Port ,  bound,  size); 
Interface.  Get— Port  ID  ("Resp^In** ,  Re  sp_I  n__Po  rt ,  bound,  size); 

Amh^Cont rol__P roc es  sing  (Process^ID) ; 

Interface . Pini sh; 
return; 

end  AMH_Cont ro 1 ; 

Figure  3-2:  AMHS_Control  Task  Implementation 


3.2.  A  Compound  Task  Description  and  Its  Structure 

The  Durra  language  supports  hierarchical  task  descriptions.  The  previous  section  illustrated 
a  simple  task  description  and  its  implementation.  The  task  used  in  that  example  is  one  of 
several  components  of  the  Automated  Message  Handling  System  (AMHS).  In  this  section 
we  will  use  this  and  other  similar,  simple  tasks  to  describe  the  complete  message  handler 
shown  in  figure  3-4. 

The  “AMHS’’  subsystem  consists  of  five  tasks.  Three  of  these  tasks,  “AMHS_control,” 
“AMHSJnbound,"  “AMHS_outbound,"  are  user-implemented  (“AMHS_control’’  was  shown 
in  the  previous  section,  the  other  two  appear  in  Appendix  B).  The  other  two  tasks, 
"broadcast"  and  “merge"  are  predefined  in  the  Durra  language  and  implemented  directly  by 
the  Durra  runtime  system.  A  “broadcast”  task  takes  data  from  a  single  input  port  and  copies 
it  to  multiple  output  ports  (the  number  of  output  ports  is  specified  in  the  task  spi°ction.  A 
“merge”  task  takes  data  from  multiple  input  ports  (specified  in  the  task  selection)  n-’d  copies 
them  into  a  single  output  port. 
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procedure  Read_Next_Me««age (M«g_Type :  in  out  Mea«age_Type)  ia 
Read_Cycle_Delay  :  Duration  :»  0.5; 

Durra_type,  size,  n  :  natural; 
begin 

Read_Loop : 
loop 

Interface .  Te  st_Input_P ort  (  SM_In_Port , 

Durra_Type , 
size, 

n) ; 

if  n  >  0  then 

Interface . Get_Port (  SM_In_Port , 

Cxnd_Msg '  Addres  s , 
size, 

Msg_Typ«) ; 

exit  Read_Loop; 
end  if; 

Interface .  Test^Input_Port  (  Resp__In_Port , 

Durra_type , 

size, 

n)  ; 

if  n  >  0  then 

Interface .  Get__Port  (  Resp^In^Port , 

Rsp_Msg'  address, 
size, 

Msg^Type)  ; 

exit  Read_Loop; 
end  if; 

delay  Read_Cycle_Delay; 
end  loop  Read_Loop; 
return; 

end  Read_Kext_Hessage; 

Figure  3-3:  Sample  Sequence  of  Port  Operations 


The  application  description  instantiates  five  processes  ("ac,"  ”ai,"  ‘’ao,"  "pb,"  and  “pm”), 
corresponding  to  the  five  tasks  mentioned  above  and  six  queues  ("ql”  through  Mq6")  that 
connect  the  processes’  ports.  Notice  that  not  all  the  internal-task  ports  are  connected.  This 
group  of  tasks  implements  a  subsystem  which  can  be  used  as  a  building  block  for  a  larger 
system  (the  C3I  node,  in  this  case,)  and  therefore  must  also  have  ports  to  communicate  with 
other  subsystems.  Since  the  subsystem  is  really  an  abstraction  and  does  not  really  cor¬ 
respond  to  a  executable  program,  its  ports  ("SM_Commands,”  ,,SM_Response1'’ 
"COMMJnbound,"  "COMM_Outbound,”  "WSJnbound,"  and  "WS_Outbound")  must  be  im¬ 
plemented  by  internal-task  ports.  This  is  the  purpose  of  the  bind  declarations,  which  declare 
the  internal-task  ports  that  implement  or  correspond  to  the  subsystem  ports. 
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task  AMHS 

—  Automat ad  Mas saga  Handling  Subsystem 
ports 


SM_C  otrtmand  s 
SM_Rasponsas 
COMM_I  nbound 
COMM_Outbound 
WS_I nbound 
WS_Outbound 
structura 

procass 


in  sy  st  em_c  ommand  ; 

out  subsystam^rasponsa ; 

in  coznn^if^iMssaga; 

out  comm_i f _ma  s s aga ; 

out  workstation_i£_massaga; 

in  comm_i f _ma  s  s aga ; 


bind 


quaua 


and  AMHS; 


ac 

:  task 

AMHS_cont  ro  1 ; 

ai 

:  task 

AMHS_inbound; 

ao 

:  task 

AMHS_outbound 

pb 

:  task 

broadcast 

port 

ini  :  in  systam_command; 

outl,  out 2  :  out  systarn^command; 

and  broadcast; 
pm  :  task  marga 

port 

ini,  in2  :  in  subsystam^rasponsa; 
outl  :  out  subsystain^rasponsa; 

at tribute 

mode  m  £i£o; 

and  marga; 


SM_Coxmnands 
SM_Rasponsas 
COMM_I  nbound 
COMM_Out bound 
WS_I  nbound 
WS  Outbound 


■  ac.SM_In; 

■  ac.SM_Out; 

■  ai .  COMM_Inbound; 

»  ao .  COMM_Outbound; 
*»  ai  .WS_Inbound; 

a  ao  .  WS  Outbound; 


qi 

q2 

q3 

q4 

q5 

q6 


ac .  Cmd__Out 

» 

pb. ini; 

pb.outl 

» 

ai .  Cxnd__In  ; 

pb.out2 

» 

ao . Cmd_In ; 

ai  .Rasp__Out 

» 

pm. ini; 

ao  .Resp_Out 

» 

pm.  in2; 

pm .  out  1 

» 

ac. Rasp_In; 

Figure  3-4:  AMHS  Subsystem  Description 


3.3.  An  Application  Description 

In  this  section  we  illustrate  a  complete  application  description.  There  are  no  special  lan¬ 
guage  features  beyond  those  used  to  describe  a  compound  task.  An  application  description 
is  simply  a  compound  task  description  which  is  compiled  and  stored  in  a  Durra  library  and, 
conceivably,  could  be  used  as  a  building  block  for  a  larger  application. 
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From  the  point  of  view  of  the  users  of  Durra,  the  main  difference  between  a  task  description 
and  an  application  description  is  that  application  descriptions  are  translated  into  directives  to 
the  runtime  scheduler  by  executing  an  optional  code  generation  phase  of  the  Durra  com¬ 
piler,  as  described  in  [3]. 

Continuing  with  the  examples  of  the  previous  sections,  let’s  assume  that  the  C3I  node  con¬ 
stitutes  the  complete  application  (i.e.,  we  are  ignoring  the  rest  of  the  network  --  it  would 
consist  of  multiple  instances  of  nodes  and  communication  tasks).  In  addition  to  the  Auto¬ 
mated  Message  Handling  System,  there  are  several  other  components  of  the  C3I  node,  as 
illustrated  in  figure  3-5. 

The  C3I  node  consists  of  five  main  subsystems  (”system_manager,”  "comm,”  "amhs,”  and 
two  instances  of  "wkstn”).  In  addition,  there  are  four  predefined  tasks  (two  broadcast  and 
two  merge)  that  serve  to  multiplex  and  demultiplex  messages  exchanged  between  the  main 
subsystems,  as  shown  in  Figure  3-6. 

The  complete  set  of  task  descriptions  and  type  declarations  used  to  build  the  application  are 
included  in  the  appendices. 
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task  configuration 
structure 
process 

—  real  system  proc aaaaa 

am  :  taak  system_manager; 

com  :  taalc  comm; 

amh  :  taalc  amha; 

wlp  :  ta sk  wkstn; 

w2p  :  taak  wkatn; 

auxiliary  system  proc aaaaa 
dmxp:  taak  broadcast  —  maaaaga  damultiplaxor 
porta 

ini  :  in  wo  rk  a  ta  t  i  on_i  f _ma  a  a  aga ; 

outl,  out 2  :  out  workatation_i£_meaaage; 
and  broadcaat; 

ntuxp :  taak  marga  —  maaaaga  multiplexor 

porta 

outl  :  out  comra_if__massage; 

ini,  in2  :  in  corran_i£_maaaaga; 
attribute 

mo  da  *  £i£o; 

and  marga; 

be  :  taak  broadcaat 
porta 

ini  : 

outl ,  out2  : 
and  broadcaat; 
mg  :  taak  marga 
porta 

ini,  in2  : 
outl 

attribute 

mode  *  fifo; 

and  marga; 


—  command  broadcaat 

in  8yatam_consnand; 
out  ayatem_command; 

—  raaponaa  multiplexor 

in  aubayatam_reaponae; 
out  aubayatam_raaponaa; 


queue a 


—  ayatam  command  propagation 

q_cl  :  am .  SM__Out  »  be.  ini; 

q_c2  :  be. outl  »  com .  SM_Corrmanda ; 

q_c3  :  be. out 2  »  amh . SM_Commanda ; 

—  aub ayatam  raaponaa  propagation 

q_rl  :  com.  SM_Reaponsea  »  mg. ini; 

q_r2  :  amh.  SH_Raaponaaa  »  mg.in2; 

q_r3  :  mg. outl  »  am.  SM_In; 

—  inbound  maaaaga  propagation 

»  amh .  COMM_Inbound; 
»  dmxp.  ini; 

»  wlp. Inbound; 

»  w2p.  Inbound; 

—  outbound  maaaaga  propagation 

:  wlp. Outbound  »  muxp.inl; 

:  w2p .  Outbound  »  muxp .  in 2 ; 

:  muxp. outl  »  amh . WS_Outbound ; 

:  amh .  COMM_Outbound  »  com .  Outbound; 

and  configuration; 


q_ol 

q_o2 

q_03 

q_o4 


q_±l 

:  com.  Inbound 

q_i2 

:  amh .  WS_Inbound 

q_i3 

:  dmxp. outl 

q_i4 

:  dmxp. out 2 

Figure  3-5:  C3I  Node  Description 
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muxp 


4.  Software  Development  Methodologies 

A  great  deal  of  effort  has  been  devoted  to  the  development  of  improved  software  devel¬ 
opment  process  models.  As  described  in  [5],  models  have  evolved  from  the  early  “code- 
and-fix”  model,  through  the  “stagewise”  and  “waterfall”  models  (which  attempt  to  bring  or¬ 
der  to  the  process  by  recognizing  formal  steps  in  the  process),  through  the  "evolutionary" 
and  “transform”  models  (which  attempt  to  address  the  need  for  experimentation,  refinement 
of  requirements,  and  automation  of  the  code  generation  phase.)  The  spiral  model  of  the 
software  process  has  evolved  over  several  years  at  TRW,  based  on  experience  on  a  num¬ 
ber  of  large  software  projects  and,  as  indicated  in  [5],  accommodates  most  previous  models 
as  special  cases. 

The  spiral  model  is  basically  a  refinement  of  the  classical  waterfall  model,  providing  for  suc¬ 
cessive  applications  of  the  original  model  (requirements,  design,  development,  testing,  etc.) 
to  progressively  more  concrete  versions  of  the  final  product. 

One  of  the  advantages  of  this  model  is  that  it  allows  the  identification  of  areas  of  uncertainty 
that  are  significant  sources  of  risk.  Once  these  critical  areas  are  identified,  the  spiral  model 
allows  for  the  selective  application  of  an  appropriate  development  strategy  to  these  risk 
areas  first.  Thus,  while  at  first  sight  the  spiral  model  looks  no  better  than  the  waterfall 
model,  a  key  difference  is  that  the  spiral  allows  the  designers  to  concentrate  on  selected 
problem  areas  rather  than  following  &  predetermined  order.  Once  the  highest-risk  problem 
has  been  taken  care  of,  the  next  higher  risk  area  can  be  attacked,  and  so  on. 

To  be  successful,  any  approach  based  on  successive  refinements,  such  as  the  spiral  model, 
must  be  supported  by  tools  appropriate  to  the  task  at  hand.  Users  of  the  spiral  model  must 
be  able  to  selectively  identify  high-risk  components  of  the  product,  establish  their  require¬ 
ments,  and  then  carry  out  the  design,  coding,  and  testing  phases.  Notice  that  it  is  not  neces¬ 
sary  that  this  process  be  carried  out  through  the  testing  phase  --  higher-risk  components 
might  be  identified  in  the  process  and  these  components  must  be  given  higher  priority, 
suspending  the  development  process  of  the  formerly  riskier  component. 


4.1.  Durra  as  a  Tool  for  Successive  Refinement 

The  programming  paradigm  embodied  in  Durra  fits  very  naturally  this  style  of  software  de¬ 
velopment.  Although  we  don’t  claim  to  have  solved  all  problems  or  identified  all  the  neces¬ 
sary  tools,  we  would  like  to  suggest  that  a  language  like  Durra  would  be  of  great  value  in  the 
context  of  the  spiral  model.  It  would  allow  the  designer  to  build  mock-ups  of  an  application, 
starting  with  a  gross  decomposition  into  tasks  described  by  templates  that  are  specified  by 
their  interface  and  behavioral  properties.  Once  this  is  completed,  the  application  can  be 
emulated  using  tools  like  MasterTask  [4]  as  a  stand-in  for  the  yet-to-be-written  task  imple¬ 
mentations. 

The  result  of  the  emulation  would  identify  areas  of  risk  in  the  form  of  tasks  whose  timing 
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specifications  are  more  critical  or  demanding.  In  other  words,  the  purpose  of  this  initial 
emulation  is  to  identify  the  component  task  more  likely  to  affect  the  performance  of  the  en¬ 
tire  system.  The  designers  can  then  experiment  by  writing  alternative  behavioral  specifi¬ 
cations  for  the  offending  task  until  a  satisfactory  specification  (i.e.,  template)  is  obtained. 
Once  this  is  achieved,  the  designers  can  proceed  by  replacing  the  original  task  descriptions 
with  more  detailed  templates,  consisting  of  internal  tasks  and  queues,  using  the  structure 
description  features  of  Duma.  These  more  refined  application  descriptions  can  again  be 
emulated,  experimenting  with  alternative  behavioral  specifications  of  the  internal  tasks,  until 
a  satisfactory  internal  structure  (i.e.,  decomposition)  has  been  achieved.  This  process  can 
be  repeated  as  often  as  necessary,  varying  the  degree  of  refinement  of  the  tasks,  and  even 
backtracking  if  a  dead-end  is  reached.  It  is  not  necessary  to  start  coding  a  task  until  later, 
when  its  specifications  are  acceptable,  and  when  the  designers  decide  that  it  should  not  be 
further  decomposed. 

Of  course,  it  is  quite  possible  that  a  satisfactory  specification  might  be  impossible  to  meet 
and  a  task  implementation  might  have  to  be  rejected.  The  designers  would  then  have  to 
backtrack  to  an  earlier,  less  detailed  design  and  try  alternative  specifications,  or  even  alter¬ 
native  decompositions  of  a  parent  subsystem.  This  is  possible  because  we  are  following  a 
strictly  top-down  approach.  The  effect  of  a  change  in  an  inner  task  would  be  reflected  in  its 
impact  on  the  behavioral  specifications  of  a  parent  task.  The  damage  is,  in  sense,  con¬ 
tained  and  can  not  spread  to  other  parts  of  the  design. 


4.2.  Incremental  Development  of  the  C3I  Node 

To  illustrate  an  incremental  development  process  using  Duma,  in  this  section  we  will  show 
three  alternative  development  sequences  for  the  C3I  node.  In  all  three  cases  we  start  from 
the  same  basic  configuration  for  the  node  shown  in  Figure  4-1.  The  node  consists  of  four 
subsystems:  System  Manager,  Communications,  Application  Message  Handler,  and  Work¬ 
station. 

These  subsystems  correspond  to  the  first  four  process  declarations  in  the  structure  of  the 
Duma  application  description  in  Figure  4-1 .  In  addition,  the  application  description  declares 
two  auxiliary  tasks  which  are  used  for  communications  between  the  system  manager  and 
the  communication  and  application  message  handler  subsystems.  These  auxiliary  tasks 
broadcast  commands  from  the  system  manager  to  the  other  two  subsystems,  and  merge 
their  responses  to  the  system  manager.  The  queue  declarations  in  the  Figure  connect  the 
task  ports  in  the  appropriate  manner. 

For  brevity,  we  are  not  showing  a  simpler  configuration  that  could  have  been  our  initial  de¬ 
sign.  For  example,  we  could  have  started  with  a  node  consisting  of  two  subsystems: 
(combined)  Communications,  and  Workstation.  A  first  step  could  be  to  divide  the  first  sub¬ 
system  into  three  components:  System  Manager,  Application  Message  Handler,  and  Com¬ 
munications  proper.  We  take  this  as  our  initial  design. 
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task  configuration 
structure 
process 

—  real  system  processes 

sm  :  task  system_manager; 

com  :  task  comm; 

amh  :  task  amhs; 

wp  :  task  wkstn; 

—  auxiliary  system  processes 

be  :  task  broadcast  —  command  broadcast 

ports 

ini  :  in  system_comnand; 

outl,  out2  ;  out  system_command; 

end  broadcast; 

mg  :  task  merge  —  response  multiplexor 

ports 

ini,  in2  :  in  subsystem__response; 

outl  :  out  subsystem__response; 

attribute 

mode  *  fifo; 

end  merge; 


queues 

—  system  command  propagation 

q_cl  :  sm . SM_Out  »  be. ini; 

q_c2  :  be. outl  »  com . SM_Commands ; 

q_c3  :  be. out 2  »  amh  SM^Commands ; 

—  subsystem  response  propagation 

q_rl  :  com.  SM_Responses  »  mg. ini; 

q_r2  :  amh. SM_Responses  »  mg.in2; 

q_r3  :  mg. outl  »  sm. SM_In; 

—  inbound  message  propagation 

q_il  :  com.  Inbound  »  amh .  COMM_Inbound; 

q_i2  :  amh .  WS_Inbound  »  wp .  Inbound; 

—  outbound  message  propagation 

q_ol  :  wp. Outbound  »  amh . WS_Outbound ; 

q_o4  :  amh .  COMMjOutbound  »  com .  Outbound; 

end  configuration; 


Figure  4-1 :  Initial  Application  Description 
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Figure  4-2  shows  the  tasks  descriptions  for  the  subsystems  of  the  initial  configuration. 
Since  at  this  stage  of  the  development  we  might  not  be  ready  to  commit  to  any  particular 
structure  for  the  subsystems,  these  are  described  as  simple,  unstructured  tasks.  This  infor¬ 
mation  is  sufficient  to  do  static  checks,  including  port  (i.e.,  type)  compatibility  and  graph  con¬ 
nectivity.  We  could  continue  the  design  in  this  fashion,  successively  refining  the  subsystem 
descriptions  until,  at  the  end,  the  application  is  fully  described  as  a  hierarchical  graph  struc¬ 
ture  in  which  the  innermost  nodes  are  implemented  as  separate  programs,  specified  by  the 
"implementation”  attribute  of  the  corresponding  task  description. 

However,  if  we  want  to  carry  out  some  preliminary  dynamic  tests,  we  need  to  provide  a 
pseudo-implementation  for  each  subsystem.  That  is,  we  need  to  write  ad  hoc  programs  that 
emulate  the  input/output  behavior  of  each  of  the  subsystems  and  then  specify  these  pro¬ 
grams  as  the  "implementation"  attributes  in  the  subsystem  task  descriptions.  Alternatively, 
if  a  subsystem’s  behavior  is  relatively  simple  and  repetitive,  we  could  use  "MasterTask" 
[4]  as  a  subsystem  emulator.  To  use  MasterTask,  we  need  to  include  a  timing  expression 
in  the  subsystem  task  description,  and  specify  "master"  as  its  "implementation"  attribute.  In 
fact,  we  can  mix  the  two  approaches  and  have  some  subsystems  emulated  by  ad  hoc  pro¬ 
grams,  while  other  subsystems  are  emulated  via  MasterTask,  as  shown  in  Figure  4-2. 

Figures  4-4,  4-5,  and  4-6  show  three  possible  design  sequences  starting  from  the  original 
design  of  Figure  4-1  and  ending  with  the  final  design  shown  in  Figure  4-3.  In  Figure  4-4  we 
first  replicate  the  workstation,  then  we  decompose  the  communication  and  application  mes¬ 
sage  handlers,  and  finally  we  decompose  the  workstations.  In  Figure  4-5  we  first  decom¬ 
pose  the  communication  and  application  message  handler  subsystems,  .then  we  replicate 
the  workstation,  and  finally  we  decompose  the  workstation.  In  Figure  4-6  we  carry  out  the 
design  in  yet  a  different  order.  First  we  decompose  the  communication  and  application  mes¬ 
sage  handler  subsystems,  then  we  decompose  the  workstation,  and  finally  we  replicate  the 
workstation. 

There  are  a  number  of  other  alternative  design  sequences  leading  to  the  same  final  design 
and  we  do  not  need  to  belabor  the  point. 
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task  ayatem__manager 
porta 

SH_In  :  in  aubayatem_re aponae; 

SM_Out  :  out  ayatera_command; 
attribute a 

implementation  =»  "  ayatem_manager_emulatorM ; 
proceaaor  ■  "Vu"; 
end  ayatem_manager; 

a  --  System  Manager  Subsystem 


taak  comm 

—  red  coraraunicationa 
porta 

SM_Command  a 
SM_Re apona e a 
Inbound 
Outbound 
attribute a 


proceaaing 

in  ayatem_command; 
out  aubay atem_re aponae ; 
out  corom^if^zneaaage; 
in  comm_i  f_me  a  sage ; 


implementation  ■  "comm_ernulatorH  ; 
proceaaor  —  "Vax"; 
end  comm; 


b  --  Communications  Subsystem 


taak  AMHS 


—  Automated  Meaaage  Handling  Subayatem 
porta 


SMjCommanda 
SM_Reaponaea 
COMM^I  nbound 
COMM_Outbound 
WS_I nbound 
WS  Outbound 


in  ayatem_command; 

out  aubay a tem_re aponae; 

in  comm_i  f_mea  aage ; 

out  comm_if_meaaage; 

out  workatation_if _mea aage ; 

in  comm_i  f_me  a  a  age ; 


attribute a 

implementation  »  "amha_emulator” ; 
proceaaor  ■  "Vax"; 
end  AMHS; 


c  --  Application  Message  Handler  Subsystem 


taak  wkatn 
porta 

Inbound  :  in  workatation_if_ma8  8age; 

Outbound  :  out  comm__if__me88age; 

behavior 


timing 

loop 

(  (Inbound. dequeue  delay[5r  60])  || 

(delay  [*,  180]  Outbound. enqueue)  ); 


attribute a 

implementation  =  "maater"; 
proceaaor  ■  "Vax"; 
end  wkatn; 


d  --  Workstation  Subsystem 
Figure  4-2:  Initial  Task  Descriptions 
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Workstation  2 

Figure  4-3:  Final  Structure  of  the  C3I  Node 


32 


CMU/SEI-89-TR-9 


Figure  4-4:  Incremental  Development  of  the  C3I  Node  —  Sequence  1 
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System  manager 


Figure  4-6:  Incremental  Development  of  the  C3I  Node  —  Sequence  3 
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5.  Conclusions  and  Future  Developments 

This  report  contains  the  results  of  the  first  phase  of  a  joint  project  between  the  Software 
Engineering  Institute  and  TRW  Defense  Systems  Group.  The  objective  of  this  project  is  to 
demonstrate  a  new  technology  for  developing  distributed  applications  on  networks  of  hetero¬ 
geneous  machines.  We  have  chosen  as  the  initial  application  domain  prototype  C3I  applica¬ 
tions  built  using  the  C3I  testbed  developed  by  TRW  and  the  Durra  language  and  method¬ 
ology  developed  by  the  SEI. 

To  help  provide  direction  to  the  effort  and  to  evaluate  our  progress  we  identified  three  major 
phases:  Basic  Demonstration,  Study  of  Networking  Issues,  and  Advanced  Demonstration. 
This  report  describes  the  results  of  the  first  phase.  The  second  and  third  phases  will  be  the 
subject  of  a  report  scheduled  for  the  fall  of  1989. 


5.1 .  Basic  Demonstration 

The  goal  of  the  first  phase  was  to  demonstrate  the  basic  functionality  of  a  command  and 
control  application  developed  using  Durra  and  the  capability  of  supporting  heterogeneous 
networking.  In  addition  to  demonstrating  the  application  development  methodology,  the 
sample  applications  developed  for  the  demonstration  will  provide  an  experimental  facility  for 
future  performance  measurements  and  evaluations.  We  accomplished  this  goal  through 
several  intermediate  subgoals: 

Defined  common  communication/scheduier  primitives.  The  Durra  model  of  computation 
assumes  the  use  of  a  small  set  of  message  passing  primitive  operations.  The  TRW  testbed 
tasks  also  use  a  message  passing  paradigm  but  their  original  interface  was  not  as  narrowly 
defined  as  in  Durra.  The  narrow  interface  was  adopted  as  the  first  step  of  the  project  and 
we  modified  the  testbed  software  to  use  the  Durra  scheduler  interface.  . 

Developed  Durra  descriptions  of  C3!  tasks,  subsystems,  and  node.  We  analyzed  the 
testbed  modules  and  developed  Durra  descriptions  of  the  tasks.  Writing  these  descriptions 
required  an  understanding  of  the  behavior  of  the  testbed  tasks,  their  performance  and  com¬ 
munication  requirements  (ports  and  message  types),  and  the  structure  of  typical  applica¬ 
tions  in  the  C3I  domain.  We  also  developed  Durra  descriptions  of  the  subsystems,  defined 
by  TRW  as  the  architecture  of  the  C3I  node. 

Demonstrated  the  methodology.  All  of  the  Durra  task  descriptions  and  the  modified  test¬ 
bed  modules  were  compiled  and  the  distributed  C3I  node  executed  as  expected,  on  the 
computer  networks  at  the  SEI  and  at  TRW  Defense  Systems  Group,  using  two  types  of 
workstations  (MicroVax  and  Sun),  two  versions  of  Unix  (Ultrix-32  and  BSD-4.3),  and  two 
versions  of  X  windows  (X10  and  XII). 
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5.2.  Study  of  Advanced  Networking  Issues 

Following  the  successful  demonstration  of  the  basic  methodology,  we  need  to  explore  the 
extension  or  modification  of  the  Durra  paradigm  of  networking  to  meet  more  realistic  C3I 
requirements. 

System  robustness  issues.  The  current  implementation  of  Durra  uses  a  centralized 
scheduler.  This  was  done  mostly  for  expediency,  to  get  the  system  up  and  running  in  a  short 
time.  It  was  always  understood  that  a  centralized  critical  resource  was  not  acceptable  as  a 
long  term  solution.  We  are  in  the  process  of  designing  and  implementing  a  distributed 
scheduler  to  enhance  the  reliability  and  availability  of  the  applications. 

Dynamic  application  startup/reconfiguration.  The  initial  reconfiguration  features  of  Durra 
are  based  on  a  preset  (i.e.,  compile  time)  description  of  the  conditions  for  a  change  and  the 
nature  of  the  change  in  the  configuration  of  an  application.  This  model  might  be  too  restric¬ 
tive  for  a  number  of  applications,  and  we  will  investigate  the  issues  involved  in  developing 
an  interactive  scheduler  interface  to  allow  human  operators  to  invoke  arbitrary  application 
reconfigurations. 

Default  reconfiguration  actions.  These  two  styles  of  reconfiguration  (preset  and 
interactive)  might  not  be  adequate  to  cope  with  all  possible  system  anomalies  that  would 
trigger  a  reconfiguration.  A  Durra  description  that  would  attempt  to  cover  all  possible 
anomalies  will  be  unwieldy,  unreadable,  and  most  likely  incomplete.  By  the  same  token,  an 
operator  might  be  swamped  by  the  speed  of  events  or  confused  as  to  the  best  action  to  take 
under  real-time  conditions.  Thus,  there  is  need  for  default  reconfiguration  actions  to  be  fol¬ 
lowed  by  the  scheduler.  These  defaults  should  not  be  built-in  but  rather  should  be  a  prop¬ 
erty  of  the  application  and  might  vary  over  time,  during  the  life  of  the  application.  We  will 
investigate  appropriate  policies  for  taking  default  reconfiguration  actions  and  the  languages 
for  specifying  these  policies. 


5.3.  Advanced  Demonstration 

The  goal  of  this  phase  will  be  to  demonstrate  dynamic  reconfiguration  features  (preset  and 
interactive)  to  support  fault  tolerance.  This  is  planned  to  be  completed  by  September  1989. 
To  achieve  this  goal,  we  have  adopted  the  following  intermediate  subgoals: 

Demonstrate  preset  dynamic  reconfiguration.  Augment  the  Durra  application  descrip¬ 
tions  developed  during  the  first  phase  (these  descriptions  are  contained  in  this  report)  with 
dynamic  reconfiguration  statements.  This  requires  the  identification  of  typical  reconfiguration 
requirements  in  C3I  applications  and  their  expression  in  Durra. 

Develop/demonstrate  Interactive  dynamic  reconfiguration.  We  will  implement  a  system 
operator  program  to  allow  direct  communication  between  an  operator  and  the  runtime 
scheduler.  This  program  will  consist  primarily  of  a  simple  user  interface  and  a  command 
interpreter  that  will  take  requests  from  an  operator  and  will  translate  these  into  scheduler 
instructions  to  perform  interactive  reconfigurations. 
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Develop/demonstrate  policy  language  concepts.  We  will  implement  a  simple  policy  lan¬ 
guage  and  associated  mechanisms  to  handle  system  anomalies  when  neither  the  preset  nor 
interactive  reconfiguration  facilities  are  adequate. 
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Appendix  A:  C3I  Node  Application  Description 


taak  configuration 
structure 
process 

—  real  system  processes 

am  :  task  systam_manager; 

com  :  task  comm; 

amh  :  task  amha; 

wlp  :  task  wkatn; 

w2p  :  task  wkatn; 

auxiliary  system  procaaaaa 
dmxp:  taak  broadcaat  —  maaaaga  damultiplaxor 
porta 

ini  :  in  workstation_if_massage; 

outl ,  out2  :  out  workstation_if__message; 
and  broadcaat; 

muxp:  taak  marga  —  maaaaga  multiplaxor 

porta 

outl  :  out  comm_if_mes  saga ; 

ini ,  in2  :  in  comm_if_massaga; 
attributa 

mo  da  a  f  if  o; 

and  marga; 

be  :  taak  broadcaat  —  command  broadcaat 

porta 

ini  :  in  systam_coramand; 

outl ,  out2  :  out  systam_coxrinand; 

and  broadcaat; 

mg  :  taak  marga  —  response  multiplaxor 

porta 

ini  r  in2  :  in  subsystam_responsa; 

outl  :  out  sub8y8tam_ra8pon8a; 

attributa 

mo  da  »  fifo; 

and  marga; 


quauaa 

—  ayatam  command  propagation 


C[_d 

am .  SM_Out 

»  be. ini; 

q__c2 

be . out 1 

»  com .  SM_Consnainda  ; 

q  c3 

be .out 2 

»  amh.SM  Commands; 

—  subayatam  response  propagation 

q_ri 

com. SM^Raaponaaa 

»  mg. ini; 

q_r2 

amh . SM_Responses 

»  mg . in2 ; 

q_r3 

mg. outl 

»  am.  SM_In; 

—  inbound  maaaaga  propagation 

q_il 

com.  Inbound 

»  amh . COMM_Inbound 

q_i2 

amh .  WS_Inbound 

»  dmxp. ini; 

q_i3 

dmxp . out 1 

»  wlp.  Inbound; 

q_14 

dmxp . out2 

»  w2p .  Inbound; 

—  outbound  maaaaga  propagation 

q_ol 

:  wlp .  Outbound 

»  muxp.  ini; 

q_o2 

:  w2p .  Outbound 

»  muxp .  in  2 ; 

q_03 

;  muxp. outl 

»  amh .  WS_Outbound; 

q_o4 

:  amh .  COMM__Out bound 

»  com. Outbound; 

and  configuration; 
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Appendix  B:  Application  Message  Handler  Description 


B.l.  Subsystem  Description 


task  AMHS 

—  Automat  ad  Has  saga  Handling  Subsyatam 
ports 

SM_Command  s 
SM_Ra spon s as 
COMM_I  nbound 
COMM_Out  bound 
WS  Inbound 


WS_ 
structura 

procass 


Outbound 


ac 

ai 

ao 

pb 


pm 


sy  s t  ftm_conmand ; 
subsystam^ra  spon  s  a ; 
con*n_if_ma  s  s  aga ; 
coram_if_ma  s  saga  ; 
workstat  ion_if _mas  saga ; 
comm_i  f _xna  s  s  aga ; 


bind 


in 

out 

in 

out 

out 

in 


task  AMHS_control; 
task  AMH S_inboun d ; 
task  AMHS_outbound; 
task  broadcast 
port 

ini 
outl , 

and  broadcast; 
task  marga 
port 

ini, 
outl 
attributa 

moda  a  fifo; 

and  marga; 


out  2 


in2 


in  systam_coiwnand; 
out  systam_command; 


in  subsystam_rasponsa; 
out  subsystam_ra8ponsa; 


quaua 


and  AMHS; 


SM_Commands 
SM_Rasponsas 
COMM_I  nbound 
COMM_Out  bound 
WS_I  nbound 
WS  Outbound 


-  ac . SM_In ; 

-  ac.SM_Out; 

*  ai .  COMM_Inbound; 

»  ao . COMM_Outbound ; 
«  ai .  WS_Inbound; 
a  ao.WS  Outbound; 


qi 

q2 

qa 

q4 

q5 

q6 


ac .  CradjOut 

» 

pb . ini; 

pb.outl 

» 

ai . Cmd_In ; 

pb.out2 

» 

ao .  Cmd_In ; 

ai . Rasp_Out 

» 

pm.  ini; 

ao .  RaspjOut 

» 

pm.  in2; 

pm.  outl 

» 

ac .Rasp_In; 
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B.2.  Component  Task  Descriptions 

B.2.1.  Control  Task 

task  axnha_cont.ro  1 
porta 

SM_In  :  in  ayatam_coxnmand; 

SM_Out  :  out  aubaystem_response; 
Cmd_Out  :  out  ay  at  am_c  omman  d ; 
Reap_In  :  in  aubsyatam_reaponse; 
attributes 

implementation  *  "amh_control"  ; 
xlOwindow  =  "-80x12+0+0"; 
xllwindow  -  "-geometry  80x12+0+0"; 
processor  -  sun; 
end  amhs  control ; 


B.2.2.  Inbound  Message  Task 


task  amhs_inbound 
ports 


Cmd_In 
Reap_0ut 
C0MM_I abound 
WS  Inbound 


in  sy  s  t  em__c  ommand  ; 
out  sub8y8tem_re8ponse; 
in  comm_i £_me  a  a  age ; 
out  workatation_i£_message; 


attributes 

implementation  —  "  amh_inbound"  ; 
xlOwindow  -  "-80x12+0+190"; 
xllwindow  -  "-geometry  80x12+0+190"; 
processor  —  sun; 
end  amhs  inbound; 


B.2.3.  Outbound  Message  Task 


task  axnh s _ outbound 

ports 

Cmd_In  ;  in 

Resp_Out  :  out 

C0MM_0utbound  :  out 

WS_0ut bound  :  in 

attributes 

implementation  -  "amh_outbound” ; 
xlOwindow  -  "=80x12+0+380”; 


sy  s  t  em_c  ommand ; 
subsy s tem_re spon s e ; 
comm_i£_me  s  a  age ; 
comm_if  _me  s  a  age ; 


xllwindow  =  "-geometry  80x12+0+380”; 
processor  —  sun; 
end  amhs  outbound; 


46 


CMU/SEI-89-TR-9 


Appendix  C:  Communications 


C.l.  Subsystem  Description 


task  comm 

—  rad  communications 
ports 

SM_Commands 
SM_Ra s pons a s 
Inbound 
Outbound 
structure 

procsss 

cc 

ci 

co 

pb 


pm 


processing 

:  in  aystam_command; 

:  out  subsystem_response; 
:  out  comm_if_message; 

:  in  comrn_if_massage; 


:  task  comm_control; 

:  task  comm^inbound; 

:  task  c omm_ou tboun d ; 

:  task  broadcast 
port 

ini  :  in  systam_coxmnand; 

outl ,  out2  :  out  systam_command; 

and  broadcast; 

:  task  merge 
port 

ini  f  in2  :  in  subsystem__response; 
outl  :  out  subsystam__response; 

attribute 

mode  =a  f±fo; 

end  merge; 


bind 


queue 


end  comm; 


SHjCommands  =*  cc . SM_ 

In; 

SM_Rasponses  =  cc .  SM_ 

_Out; 

Inbound 

=*  ci .  Inbound; 

Outbound 

=*  co. Outbound; 

qi 

cc .  Cmd_Out 

» 

pb.inl; 

q2 

pb.outl 

» 

ci . Cmd_In ; 

qa 

pb . out 2 

» 

co .  Cmd__In ; 

q4 

ci .  Resp__Out 

» 

pm.  ini; 

qs 

co .  Resp_Out 

» 

pm.  in2; 

q6 

pm.  outl 

» 

cc.Resp_In; 

q7 

co .  Echo_Out 

» 

ci.Echo_In; 
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C.2.  Component  Task  Descriptions 


C.2.1.  Control  Task 

task  comm_control 
ports 

SM_In  :  in  system_comraand; 

SM_Out  :  out  subsystem^ rtspoass; 
Cmd^Out  :  out  system_command; 

Resp_In  :  in  subsystem_response; 
attributes 

implementation  =  "rcom_ control”; 
xlOwindow  -  "=80x12+510+0"; 
xllwindow  =  "-geometry  80x12+510+0"; 
processor  =  sun; 
end  comm  control; 


C.2.2.  Inbound  Message  Task 


task  comm— inbound 
ports 

Cmd_In 
RespjOut 
Inbound 
Echo_In 
attributes 

implementation  »  "  rcom_inbound" ; 
xlOwindow  =  "=80x12+510+190"; 
xllwindow  »  "-geometry  80x12+510+190"; 
processor  =  sun; 
end  comm  inbound; 


in  system_command; 
out  subsy a tem_re spon  se ; 
out  corr*n_if_maasage; 
in  comm_if_roes  sage ; 


C.2.3.  Outbound  Message  Task 


task  comm_outbound 
ports 

Cmd_In 
Resp_Out 
Outbound 
Echo_jOut 
attributes 

implementation  *  "  rcom_outbound" ; 
xlOwindow  =  "=80x12+510+380"; 
xllwindow  =  "-geometry  80x12+510+380"; 
processor  =  sun; 
end  comm  outbound; 


:  in  system^command; 

:  out  aub8yatem_response; 
:  in  comm_if_message; 

:  out  comm_if _me  s  sage ; 
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Appendix  D:  System  Manager  Description 

task  systam_manager 
ports 

SM_In  :  In  subsystsm_rosponss ; 

SM_Out  :  out  systam_cornmand; 
attributes 

implementation  ■  "systam^managar"; 
xlOwindow  -  "-80x12+200+570"; 
xll window  -  "-geometry  80x12+200+570"; 
processor  —  sun; 
and  systam_manager; 
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Appendix  E:  Workstation  Description 

To  preserve  proprietary  information,  we  do  not  show  the  various  tasks  constituting  the  user's 
workstation  subsystem.  For  the  purposes  of  our  demonstration,  their  functions  were  carried 
out  by  the  workstation  manager  task. 


E.l.  Subsystem  Description 

task  wkstn 
porta 

Inbound  :  in  workatation_if_meaaage; 

Outbound  :  out  comm_if_masaage; 

structure 

process 

wn:  task  wkatn__manager; 
bind 

Inbound  =  wm.  Inbound; 

Outbound  ■  wm.  Outbound; 

and  wkstn; 


E.2.  Component  Task  Descriptions 

E.2.1.  Manager  Task 

task  wkatnjmanager 
porta 

Inbound  :  in  workatation_if_measage; 

Outbound  :  out  comm__if__message; 

attributes 

processor  ■  sun; 
xl Owindow  m  "*80xl2+0+740" ; 
xllwindow  ■  " -geometry  80x12+0+740”; 
implementation  ■  "usi^sim"; 
end  wkstn_manager; 
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Appendix  F:  Type  Declarations 

type  byte  is  size  8; 

type  comm_if_message  is  array  of  byte; 

type  string  is  array  of  byte; 

type  subsystem_response  is  array  of  byte; 

type  system_coxnroand  is  array  of  byte; 

type  workstation_if_message  is  array  of  byte; 
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Appendix  G:  Scheduler  Interface  for  Ada  Task 
Implementations 

with  system;  use  system; 
package  Interface  is 


Durra  Scheduler  Interface  (Low  Level) 

This  package  provides  the  interface  to  the  Durra  scheduler  for  tasks 
written  in  Ada. 


The  init_*  variables  are  the  parameters  passed  by  the  server  when  a 
task  is  initialized.  The  server  in  turn  gets  them  from  the  scheduler. 


—  REVISION  HISTORY 

—  01/03/88  mrb 

—  06/13/88  dd 


—  07/5/88 


dd 


Package  spec  created. 

Test_Port  expanded  to  separate  routines  for 
input  and  output  ports. 

Constant  environment  names  changed  to  function  calls. 


function  UaerJTaak_Name 
function  Scheduler_Host 
function  Scheduler_Port 
function  User_Process_ID 
fun ct i on  S chedul e r_Debug_Le v« 
function  Dser_Source_Paramet« 

procedure  Finish; 


return  STRING 
return  STRING 
return  STRING 
return  STRING 
return  STRING 
return  STRING 


procedure 

Get_Port  (Port_ID 

in 

POSITIVE; 

Data 

in 

System .  Addres  s ; 

Data_Size 

out 

NATURAL; 

Type_ID 

out 

NATURAL) ; 

procedure 

Get_PortId  (Port__Name 

in 

STRING; 

Port_ID 

out 

POSITIVE; 

Queue_Bound 

out 

POSITIVE; 

Data_Size 

out 

NATURAL) ; 

procedure 

Get_TypeId  (Type_Name 

in 

STRING; 

Type_ID 

out 

NATURAL; 

Type^Size 

out 

NATURAL) ; 

procedure 

Init; 

procedure 

Sond_Port  (Port_ID  :  in  POSITIVE; 

Data 

Data_Size 

Type_ID 


in  System.Address ; 
in  NATURAL; 
in  NATURAL) ; 


procedure  Test_Input_Port 


(Port_ID 

Type_o  f _N  ext  _I  npu  t 
Si  z  e_o  f _Next  _I  nput 
Input  s_in_Queue 


procedure 
end  Interf 


Test_Output_Port  (Port_ID 

Space s_Ava liable 


in 


in 


POSITIVE; 
out  NATURAL; 
out  NATURAL; 
out  NATURAL) ; 

POSITIVE; 
out  NATURAL) ; 


ace; 
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as  they  move  from  producer  to  consumer  processes. 

This  report  describes  an  experiment  in  implementing  a  command,  control,  com¬ 
munications  and  intelligence  (C3I)  node  using  reusable  components.  The  exper¬ 
iment  involves  writing  task  descriptions  and  type  declarations  for  a  subset  of  the 
TRW  testbed,  a  collection  of  C3I  software  modules  developed  by  TRW  Defense, 
Systems  Group.  The  experiment  illustrates  the  development  of  a  typical  Durra 
application.  This  is  a  three-step  process:  first,  a  collection  of  tasks  (programs)  is 
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of  task  descriptions  corresponding  to  the  task  implementations  is  written  in  Durra, 
compiled,  and  stored  in  a  library;  and  finally,  an  application  description  is  written  in 
Durra  and  compiled,  resulting  in  a  set  of  resource  allocation  and  scheduling  com¬ 
mands  to  be  interpreted  at  runtime. 

This  report  illustrates  the  methodology  for  building  complex,  distributed  systems 
supported  by  Durra.  It  does  not,  however,  illustrate  all  the  features  of  the  lan¬ 
guage;  in  particular,  it  does  not  illustrate  those  features  that  support  dynamic,  but 
planned,  reconfiguration  of  a  running  application,  or  those  features  supporting  un¬ 
planned  dynamic  reconfigurations  as  a  means  to  support  fault  tolerance.  These 
considerations  are  the  subject  of  current  design  and  development  and  will  be  the 
subject  of  a  future  report. 


